Thank you dipthegeezer for opening this issue, it was on my todo list for a long time but I never take the time to wrote it. So, yes, it would be nice if ES instance does not start right after RPM installation.

I have this problem to. I'm trying to bring up elasticsearch in a cluster, and it is autostarting standalone because it does not have a config file yet. This causes split brained situations. This is very bad. Trying to shut down the service right away sometimes fails as well due to the pid not getting written out yet.

I tried putting "exit 0" in /etc/sysconfig/elasticsearch as a work around, but the rpm is also not treating that file as a config file and is overwriting it always.

So, there seems to be no reliable way to work around this issue without fixing the rpm.

I have a long-standing, hard to reproduce split brain issue when starting new nodes; hadn't considered that this could be the cause. Hope the referenced pull request gets merged soon!

I would also vote for not starting ES in postinstall script.

If @dipthegeezer's PR is not going to make it in then I am proposing a little relaxed alternative.
Let's replace line https://github.com/elasticsearch/elasticsearch/blob/master/src/rpm/scripts/postinstall#L38 in postinstall with something like

if [ "$ELASTICSEARCH_POST_INSTALL_STARTUP" != "false" ] ; then
    startElasticsearch
fi

Now you can do

export ELASTICSEARCH_POST_INSTALL_STARTUP=false;
yum install elasticsearch-0.90.5-1.noarch.rpm;

to have ES installed but not started.

Interesting idea, though I don't think that would work in the kickstart case.

I would also set a bad precedent. If every network service rpm needed its own env variable like this, you'd end up with:
ELASTICSEARCH_POST_INSTALL_STARTUP=false
APACHE_POST_INSTALL_STARTUP=false
TOMCAT_POST_INSTALL_STARTUP=false
INETD_POST_INSTALL_STARTUP=false
...
yum do something.

And it just snowballs.

Sorry for my ignorance @kfox1111 but are you saying that Tomcat or Apache get started when you do?

yum install <official>.rpm

I would like to use official ES RPM as much as possible but due to this autokickstart feature I have to build and ship custom RPM internally. BTW, I double checked with my colleagues (Fedora developers and official package maintainers) and they confirmed that what is stated in the link that @dipthegeezer pointed out is a valid recommendation and is also followed in RHEL.

May be I missed something.

No, sorry, I meant, if the elasticsearch rpm expects to be able to set variables to do this, then what is stopping the Apache rpm from wanting to do the same, and then the Tomcat folks, and then... Everyone will want to do it this way. It will eventually become an unmaintainable mess of packages. While it seems like a good idea at a single package level, when you have systems of lots of packages, it is much harder on the user since the user now has to know all of the environment variables (s)he has to set before doing an install for any package that may get sucked in.

@kfox1111 seriously, why would they wanted to copy this approach? Starting the service after installation is just one command away ([sudo] services tomcat start) however ppl usually want to configure services before they start them (as well as I do want to configure ES before it is started). I just do not understand the rationale about why Elasticsearch RPM does it differently. That is all. And the workaround I proposed can just provide a small workaround for me (and may be for other people) that would warmly welcome if there was a way to have it the other way around. Hope it is clear now.

//cc @spinscale please any ideas?

@lukas-vlcek: I'm agreeing with you. I think its bad to start the service automatically. Its recommended against by all rpm using distro's.

I think the reasoning ElasticSearch made, is something like: "its simpler for the user this way. They just install the rpm and then use ElasticSearch."

The point that I was trying to make is, if ElasticSearch can make this argument compellingly, why wouldn't other network services not want to follow suit. Is ElasticSearch somehow special in that it needs to be "easier to start" then other network services? Wouldn't it be nice if you just yum installed apache and it was up and running too? Its just a rabit hole that I don't think should be gone down at all. ElasticSearch, while great, is no different then any of the other network service and its rpm shouldn't behave differently then the rest. yum install it, then turn on the service when you are ready. It should not be looking at environment variables to autostart things, because there be dragons.

@lukas-vlcek Just to throw my two cents in we've had to do exactly what you've done; built and shipped our own RPM that doesn't start the service. This introduces a lot of overhead on our part in maintaining what is essentially a divergent version from the main elasticsearch code base. Especially when most documentation suggests you should never start a service on install.

Hey,

Update: I will change the packages (RPM and deb) to not start by default in the next days, along with some other features on my 'give the packages more love'-TODO list.

Not part of this ticket, but you may be interested in that as well: We are working on repositories and soon we should have something for you to try out.

Excellent! Looking forward to using rpm right away in the future 😄
Thanks @spinscale

Folks,

it would be awesome if you could comment on #4256

anything missing? Did I overlook something?

Thanks for any feedback!